Full text of "cryptolog_87-nsa"

See other formats

ADMIRAL A. I. NEPENIN: FATHER OF MODERN

RUSSIAN NAVAL INTELLIGENCE (U) J

THE CRYPT BUG (U) |. . .

USER-FRIENDLY WRITING (U)

NATIONAL SUPERCOMPUTING RESEARCH CENTER

SHELL GAME: TIME SHELLS (U) W.E.S J.IL

NSA-CROSTIC NO. 53 .David H. Williams,

AUTOMATED INFORMATION SECURITY (U) \

CRYPTOLOG 1983 INDEX (U) .

k & H S

P.L. 86-36

: ied and Approved for Release

CID : 4009895

Published by Pi, Techniques and Standards

VOL. XI, No. 2-3

FEBRUARY-MARCH 1984

PUBLISHER

BOARD OF EDITORS

Editor r

Asst. Editor ... C

Production . . |_

1 (963-3045s)
□(963-11038)
J (96 3-3369 s)

Collection |_

Computer Security

](963-3961s)

Crvptolinguistics . 1 ~

Data Systems ^

Information Science

(859-6044)
963-1103s)
] (963-4953s)

|l (963-371 Is)

Mathematics 7 ] (968-8518s)

Puzzles UdVid H. WUll&AS-r (963f 1103s)

Special Research Vera R. Filby ; (968-7119s)

Traffic Analysis .. Robert J. Hanyok^i (966-8418s)

Editorial

As an agency , we live today on yesterday *s
discoveries . Today* s output, which pays the

bills around here, is based largely upon
technical breakthroughs made sometime in the
past . Most of our people are working to pro-
duce today *s results, but here and there,
mostly in back rooms, there are a few scat-
tered people doing the " discovery " work . We
used to call them "break-in artists . ■ They are
busy making tomorrow* s production possible
and, in a very real sense, making it possible
for tomorrow* s bills to be paid .

Once in a while, one runs across d whole
cluster of this discovery work . It is jas if a
renaissance had broken out in one particular
shop . A whole group of people seem to be bub-
bling over with invention, intuition, anti
di scovery. It is an exciting place to be,

when it happens .

For subscriptions =:
send n ame and organi zation
to; | | ,P14 f

P.L. 86-36

To submit articles or letters
by mail, to: Pi, Cryptolog

via PLATFORM mail, send to:
cryptolg at barlc05
(bar-one-c-zero-f ive)
(note: no r O f in *log*)

There used to be one or two managers who
seemed to have such a renaissance around them
wherever they went. They seemed to have the
knack of creating an atmosphere that fostered
discovery, that encouraged breakthroughs .

I can remember studying those managers, to
see if I could emulate their evident ability
to stimulate the discovery process . I can

remember going to management courses and read-
ing various books on the latest fads in
management styles , looking for clues about how
to generate the atmosphere that discovery and
creativity seem to need. / can't remember
finding much that was useful ; it seemed to be
easier to talk about things that were easier
to count or measure .

Contents of Cryptolog should not be repro-
duced, or further disseminated outside the
National Security Agency without the permis-
sion of the Publisher . Inquiries regarding
reproduction and dissemination should be
directed to the Editor.

For an outfit that depends so much on
break-in artists, we ought to worry about
finding, growing, and managing tomorrow's
crop . Perhaps we already are.

4^1

F O R O FFICIAL USE ONLY

IOCID :

4009895

FOR OFFICIAL UOE OHLY

ADMIRAL A.I. NEPENIN:

FATHER OF
MODERN RUSSIAN
NAVAL INTELLIGENCE (U)

PvL. 86-36

he history of Russian military af-

W fairs has been one of incompetence
mixed with flashes of brilliance.
The brilliance has usually been in
the form of individual military
"shakers and movers 11 who have risen to the oc-
casion with determination and forcefulness to
carry through their goals , come what may, to
the end. One might include Marshals Suvorov
and Zhukov or Admirals Senyavin and Gorshkov
in this category. However, there is one indi-
vidual , although he is little known in the
West, who as a "shaker and mover" might be
said to be the father of modern Russian naval
intelligence: Admiral Adrian Ivanovich Nepe-

Nepenin, in his capacity as Chief of the
Baltic Fleet's Communications (and Intelli-
gence) Service both prior to and during World
War I, built the naval intelligence organiza-
tion into a formidable arm of the Russian Navy
and ultimately established roots which have
carried over into the Soviet era.

Adrian Ivanovich Nepenin was born 21 Oc-
tober 1871 in Pskov Province, Russia. He en-
tered the Russian Naval Academy in 1885 and
graduated in 1889. In 1898 he was assigned to
the Far East Fleet. In December 1904 Captain
2nd Rank Nepenin was assigned to command the
destroyer STOROZHEVOJ at Port Arthur. During
the war with Japan, Nepenin was captured and
spent the last part of that war as a POW in
Japan. Between 1905 and 1910 Nepenin held
various ship commands in the Baltic Fleet.

Originally prepared as an Appendix to the
author's article on "Communications Intel-
ligence and Tsarist Russia , ” which ap-
peared in the Jan 84 issue of Cryptolog .

In 1910, after much thought, Nepenin sent a
plan for reorganization of the Communications
and Observation Service of the Baltic Fleet
to Admiral Nikolaj Ottovich von Ehssen,
Coinmander-in-Chief, Baltic Fleet. Admiral von
Ehssen liked Nepenin 1 s energetic idea for the
Communications Service and in 1911 appointed
Nepenin as Chief of the Communications Ser-
vice. Nepenin probably made Captain 1st Rank
at this time.

Over the next few years, under Nepenin* s
guidance and direction, the Communicat ions
Service — almost alone within the Russian Navy
— achieved a high esprit de corps among all
its personnel. By October 1915 Nepenin had
achieved the rank of Rear Admiral for his ef-
forts. His admirers included not only his own
men but even foreign allies assigned to Russia
during the war. During a visit to a Communi-
cations Service airbase in the Baltic in 1916,
Admiral Sir Richard Phillimore (British Naval
Representative to Russian General Staff Head-
quarters, "STAVKA," 1915-16) was quoted as
telling the Communications Service officers
and men:

Feb 84 * CRYPT0L0G * Page 1

iOCID: 4009895

"Everything is excellent in our Brit-
ish Navy . . . except that we do not have
such an Admiral as your Nepenin who
knows everything."[l]

On 6 September 1916, largely on the basis
of his Communications Service record, Nepenin
was offered and accepted the command of the
Baltic Fleet along with the rank of Vice Ad-
miral. Nepenin' s time as CINC, however, was
brief with little opportunity to carry out his
ideas on reorganizing and revitalizing the
spirit of the Fleet. On 15 March 1917, while
on his way to meet with a group of disgruntles
sailors near the Helsingfors Railway Station,
Nepenin was killed by a shot from behind by
either a mutinous sailor (according to the So-
viet version) or a German agent dressed in the
uniform of a Baltic Fleet sailor (Russian
emigr£ version). [2]

Although Nepenin 1 s period on the stage of
History was brief, he left an indelible im-
print on the development of Russian naval in-
telligence in the 20th century.

FOOTNOTES

1. Apparently Sir Richard forgot (?) in his
remarks about Admiral Reginald "Blinker"
Hall of "Room 40 OB" fame,

2. Dudorov, Rear Admiral Boris Petrovich Du-

dorov in the emigr£ journal Morskie Za-
piski (The Naval Records), New York. See
also The Russian Navy in War and Revolu-
tion by G. K, Graf, Munich: R. Oldenburg,
1923, pp. 119-121, and The Russians at
Sea by David Woodward, London: William

Kimber, 1965, pp. 181-182. For the trad-
itional Soviet negative view of Nepenin
from 1916 as "suppressor of the Revolu-
tionary in the Baltic Fleet," see Pavlo-
vich, N. B. (editor), Flot v Pervoj Miro-
voj Vojne (The Navy in World War ITj 2
vols, Moscow: Voenizdat, 1964, Vol 1, p.
241.

! • cu)

P.L. 86-36

When all good folks are sound asleep.

And all the rest are counting sheep.

He concentrates on cipher text.

And contemplates ways mo9t complex
To render an approved solution
Of some obscure substitution.

While all the world is sleeping, snoring
Loud enough to rip the flooring.

He derives much satisfaction
From the spatial interaction
Of poly-graphic frequencies
And isomorphic sequences.

Of characters on paper slips
Better know as sliding strips.

Slides them West and tries the "Chi" test.
Slides them East and tries the "Phi" test,
Clamps his pipe tight in his mouth.

And grimly slides them North and South,

And if success eludes him then.

Tears them up and starts again.

Meanwhile the clock ticks on and on.

Until at long last comes the dawn.

As the milkman rattles by.

He is heard to heave a sigh.

Slowly piles the work sheets higher,

Calmly throws them on the fire.

Having proved one simple fact;

There can be do doubt of that —

As suspected all along,

Everything he did was wrong.

from Signal Corps Bulletin No. 109,
July-Dee ember 1940

Feb 84 * CRYPTOLOG * Page 2

OCID : 4009895

Human Factors

USER-FRIENDLY
WRITING (U)

P13

P . L . 86-36

e have seen and heard a lot lately
about our writing. Our Director has
made a special point of urging us to
write more clearly and directly. A
hard-hitting article on the same to-
pic may be found in the November 1983 issue of
CRYPTOLOG , pp. 13-18. A number of services
are available to help us improve our communi-
cation skills, including courses at the School
and the new "Write-Line.'* The quality and ef-
fectiveness of our writing and speaking is far
more important than many of us seem to real-
ize, in spite of these management initiatives.
Unfortunately, our writing will only get

better if we care about it and feel that it
matters. I am not going to launch into a long
article about good writing, or how to improve
our writing. That has been done already by
many others; I will mention two sources that I
have found particularly useful. But I feel
that good clear writing is an important human
factors issue, and I'd like to say a few
things about it in these Tech Notes.

I read a lot of technical papers and
research reports, and I edit my office's
Monthly Research Summaries. I am sorry to say
that I have seen a great deal of very bad
writing. It is bad because it is not "user-
friendly." I am going to direct my comments
to anyone out there who writes the kinds of
prose I have to fight my way through each
month in our Research Summary.

As a reader , I am a user of your paper or
report, just like a user of any other tool.
The paper probably says something I need to
know or I wouldn't have picked it up. If you
create long, intricate sentences choked with
jargon, you are putting major obstacles in my
way. You are making me spend far too much of
my time and energy to get your meaning. Some-
t imes your sentences are so complicated that
you lose your own way through them, so how can
you expect me, the reader, to understand them?
I know that you don't set out to mystify the
reader on purpose. I believe that scientific
and technical writers have certain basic
misconceptions about writing; some or all of
these they probably learn from their teachers
at colleges and technical schools, many of
whom are also apallingly bad writers. Let's
take a look at some of the faulty assumptions
that may give rise to the bad writing techni-
cal people so often produce.

"If I say it simply, people will think
I'm uneducated."

People in technical fields have gotten so
used to a certain very heavy, convoluted style
of writing that simpler writing just sounds
inappropriate and anticlimactic to them. Even
if they are just telling us that they debugged
a program or checked out some minor electronic
gadget, they feel they must sound like a can-
didate for the Nobel prize.

Feb 84 * CRYPTOLOG * Page 3

DOCID: 4009895

'•S ,

"If I say it simply, people won't know
it's important."

Many people seem to think that the length
of their words and the complexity of their
sentences are a direct measure of the impor-
tance of the topic. I "use" a Kleenex to blow
my nose, but I "utilize" the computer, because
the computer is a lot more expensive and im-
portant than a Kleenex or my nose! I might
"make it easier" for the cat to use the litter
box, but I feel I must "facilitate user acces-
sibility" to project X.

"If I say it simply, I won't be able to
hedge and fudge."

Technical and scientific people are masters
of the art of hedging their bets. To some ex-
tent, this is necessary and justified; we have
a professional obligation to specify the de-
gree of significance of a result , the relia-
bility of a statement, or the statistical con-
text of an event. We have to convey these
matters to our readers at those times and
places where they are important and appropri-
ate. Unfortunately, the hedging gets to be a
habit, so that it infects all our writing, and
shows up in lots of places where it serves no
purpose. ,1 suspect that the long sentences
starting out with endless strings of subordi-
nate clauses arise in this hedging habit.
Each subordinate clause is like a safe little
fence to push the bald, direct subject and

verb further away from the reader, until the
meaning disappears in a comfortable mist. I
have seen some cases where the subject and
main verb never arrive at all. In many cases,
the writer has forgotten whether the subject
was singular or plural, or even what the sub-
ject started out to be, by the time he gets to
the main verb. It's a real help to the reader
when you put the main subject and verb at or
near the beginning of the sentence. Don't get
into the habit of writing English as if it
were German!

A frequent error I see in technical writing
is the "dangling participle." The long string
of subordinate clauses at the beginning of the
sentence often starts with a participial
phrase that does not refer to the real subject
of the sentence. Strunk and White (reference
2 below) say, "A participial phrase at the be-
ginning of a sentence must refer to the gram-
matical subject." [p. 8] As the reference
states , sentences violating this rule are
often ludicrous, for example, "Being in a di-
lapidated condition, I was able to buy the
house very cheap." Even when they aren't rid-
iculous , dangling participles are confusing
and sloppy. This kind of writing doesn't im-
press a careful reader with the quality of the
writer' s thinking.

"My readers are all experts in my field
and know the jargon."

Perhaps this is true; if so, I think the
writer is making a mistake. What about
managers in other organizations that might
make use of his ideas? They may be familiar
with the field at a global level without know-
ing al 1 the buzzwords and abbreviations he
tosses off in his report. What about techni-
cal people in related fields? They may have a
similar problem with some of the jargon. Fi-
nally, I maintain that jargon and alphabet
soup are far too often a lazy substitute for
thinking. If we understand what we are doing,
we should be able to express it clearly with a
minimum of jargon. When I am talking to some-
one who throws a lot of alphabet soup and jar-
gon at me, I make a point of asking politely
for one or two definitions or expansions.
Very often, I get a blank look, a silence,
then "Well, gosh, now that you ask, I don't
know! "

Feb 84 * CRYPTOLOG * Page 4

CID : 4009895

FOR OFFICIAL USE OWL 1

"Oh, EVERYBODY knows what that means!"

The remarks in paragraph 4 apply to this
one too. I came across the phrase "reparti-
tioning the functionality" in a recent
research summary . I very much doubt that
"everybody" knows what that might mean, and
I'm sure that some simpler, clearer way could
have been found to express the idea, whatever
it was.

"If I simply say 'somebody did thus and
so,' I am leaving somebody's posterior
alarmingly uncovered."

We seem to think it is much safer for all
concerned to use the passive voice. Nobody
DID it. It just happened. It was done. That
also sounds much more impressive, like an act
of God: it rained, there was light. We've
also had it hammered into us throughout a
technical or scientific education that we must
always be "objective." The worst sin in the
world is to be "personal" or "subjective"!
That 1 s another reason why we avoid the active
voice like the plague and prefer passives or
impersonal constructions like "there were in-
dications that" and "it is apparent that."
These constructions make our sentences need-
lessly complicated right at the start: harder
for us to write, and harder for the reader to
read. At their worst, they can totally ob-
scure the meaning.

Here's a sample of user-unfriendly prose to
illustrate the needless syntactic tangles and
sloppy semantics of bad writing: "In addition
to examining the use of, and designing a
gadget for a fratnmus for project GLITCH, the
use of a widget for project FOO was also stu-
died." Exercise: find the subject of this
sentence . Here 1 s a better way of saying it :
"We designed a gadget for a frammus for pro-
ject GLITCH, and examined its use. We also
studied the use of a widget for project FOO."
I am still unhappy about the vagueness of
"studying the use" of gadgets and widgets.
Does the writer mean "try out the gadget to
see how useful it is"? Or does he mean "ob-
serve operators using the gadget and study how
they use it"? Maybe he means "perform various
experiments to see if there is any point in
trying to use the gadget . ” When we look
closely at this sentence, we see that it
doesn't convey much meaning to the reader un-
less he already knows all the intimate details
of the projects and equipment .

In closing, I'd like to stress one final
point: writing matters. It matters HOW some-
thing is expressed. Engineers and mathemati-
cians know that the formal systems they use
(mathematical and scientific notation, models,
and methods) are powerful tools. Computer
systems people hold up certain standards for
writing good code and for the efficient,
economical use of programming languages.
Technical people respect those tools and ap-
preciate the value of elegance and economy in
their use. Natural language is another tool,
just as powerful and deserving of respect.
Unfortunately, too many technical and scien-
tific workers tend to ignore or look down on
natural language. They don't think of English
as a tool that can and should be used with
elegance and skill . Their mathematics may be
beautiful, and their programs may be clear and
economical, but if their writing is messy
their minds are likely to be a bit messy too.
The exercise of stating something clearly and
directly in good plain English can often clear
up the mess for the writer as well as his
readers .

References

"Just Plain English," Department of English,
US Air Force Academy, Colorado 80840 (no
date) .

Strunk, W., Jr., and E. B. White, The Elements
of Style , New York, Macmillan, 1972

Feb 84 * CRYPTOLOG * Page 5

F O R OFFICIAL UOE ONLY

IDOCID : 4009895

National
Supercompute
Research
Center-

•

If flooo

IJfBJO

O o o

•

P.L. 86-36

Introduction

(U) A National Supercomputing Research
Center is important to NSA because it will
help us to solve many future supercomputing
problems . The word "super computing" simply
means the intelligent use of the mo9t powerful
computational tools currently available. Such
a center will probably solve these problems
better than we have done before and in a way
to help other national defense efforts as
well. It will do this with outside people and
outside money. But we need to fight for it.

Background

(U) The Chief Scientist of NSA, Mr. Kermith
Speierman, was asked by DIRNSA to formulate
NSA recommendations for DoD regarding super-
computer initiatives. The Speierman Committee
was formed to develop those recommendations
and reported to the Director in the autumn of
1983, urging four functions for a federal
supercomput ing initiative to help supercomput-
ing:

a. In-house , NSA : Highly classified special
projects ;

b. Defense Parallel Processing Laboratory

( DPPL ) : Medium-level classified work on

massively parallel processing for na-
tional security in the next decade;

c . NSRC : A largely unclassified lab for su-
percomputing hardware and software
research , with special emphasis on sup-
port of :

_d. Regional Computational Facilities (RCFs):
An unclassified program to provide super-
computer access to academic researchers.

(U) The in-house function is already being
performed and will continue. If no other ini-
tiatives are acted on, RCFs will be partially
done by the National Science Foundation (NSF)
and the Department of Energy (DoE) labora-
tories under existing plans . The really new
features are the DPPL and NSRC. But the DPPL
seems to be on its way to receiving accep-
tance. Therefore, this article is dedicated
solely to justifying the NSRC.

Feb 84 * CRYPTOLOG * Page 6

OCID : 4009895

-J

Possible Objections to the NSRC

(U) The major objections to a new* indepen-
dent NSRC are four:

The vendors typically supply poor operating
systems and FORTRAN . After all , operational
software is not their main interest and some-
thing really sophisticated is quite beyond
their current capability. The result is that
the users either get substandard performance
from their machines or have to develop new
opera t ing systems and languages , usually dif-
ferent from anybody else's.

(U) The DoE labs have developed their own
operating systems with a line editor and com-
plicated user commands that would be unsuit-
able for NSA. T he NSA supercomputing

environment — i.e., the l I svstem and IMP

language — is powerful and easy fo use. Yet it
cannot be the general super computing standard
for various technical reasons; In addition,
it is dif f icul t to trans fer to different
machines. If we soon have a wide variety of
supercompute rs, it wil l be impossible for us
to maintain I I lMP on / all without a

great increase in the number of systems pro-
grammers. UNIX/C may become the de_ facto

standard since it will boon i be available on
almost all supercomputers . However, we see it

as having inherent inefficiencies that make it
difficult to use the full power of the com-
puter when we wish to. D T

1. No need because of current open research;

2. The DoE labs could do this (and they want
to) ;

3 . An intense , open research program would
transfer information and technology to
the outer world; and

4. Suggestions for an NSRC would arouse op-
position from DoE or the President's Of-
fice of Science and Technology Policy
(OSTP) and thus possibly imperil the
whole initiative.

(U) I believe that objections 1 and 2 are
essentially false (as stated) and that 3 and 4
are true but can still be handled.

Objection 1

(U) One possible response is to put this
problem in the DPPL or keep it in NSA (by us-
ing more people). But the systems programming
problem is essentially unclassified . How much
better to free up NSAers and DPPLers for clas-
sified work and put systems software in the
NSRC, where it will be serving an independent
need anyway (support of the regional centers).
Driven by a variety of applications from
academia, with a few clever interns from the
labs and NSA bringing the best of their
methods, the NSRC could have a resounding suc-
cess. Specifically, they might well develop
once and for all a portable , easy, powerful
environment that could be used by all and
enhance the vendors' products at the same
time. And the really great thing is the lev-
erage we get by having this work done by other
people with others' money. Similar statements
could surely be made in the other areas of
NSRC emphasis besides languages and operating
systems ; i.e. , algorithms, hardware technol-
ogy , architecture, numerical analysis, artifi-
cial intelligence, and graphics.

(U) This objection is that no radically new
efforts in unclassified supercomputing
research are necessary because of existing
work in government, industry, and academia.
However , a look at specific examples (e.g. ,
operating systems and software) shows how
inadequate the current efforts really are.

Feb 84 * CRYPTOLOG * Page 7

DOCID: 4009895

Objection 2

(U) Los Alamos National Labs would dearly
love to have the functions of the NSRC. How-
ever, even a casual glance at their record
must produce skepticism inasmuch as:

[] they get relatively poor performance from
their Crays (the current standard super-
computers) ;

[] they have a clumsy operating system;

[] they discourage assembly language and
modern high-level languages; and

[] they have relatively few experts, partly
because they have not encouraged (as NSA
has) scientific personnel to become rela-
tively sophisticated.

(U) Maybe they will change if the labels on
their doors are changed, but I doubt it. And
I doubt that even "safeguards" written into
new terms of reference, or even a change of
location, would really change their modus
operand i . If Los Alamos gets the NSRC, then I
predict that the whole effort will be ir-
relevant to NSA and we will be back to having
to use many NSAers and DPPLers to do unclassi-
fied work.

Objection 3

(U) The Speierman federal initiative would
result in some information transfer to the
outside. However, since the outside world is
no longer very far behind us, the real ques-
tion is what will be the marginal increase in
harm (as opposed to what would happen anyway),
weighed against the potential benefits to us.
Since the in-house programming and the DPPL
are classified, the only threat comes from the
regional centers and the NSRC. The regional
centers should provide only computational ac-
cess at the end of a telephone line, and that
only by grant. Thus the foreign graduate stu-
dent in astrophysics could get time to study
galactic structure, but he could not dump
critical software, and he would have to break
the terms of his grant to study cryptography
on the sly. The NSRC itself should be physi-
cally restricted to US nationals since it will
have at least company proprietary, and possi-
bly classified, information. The problem with
the NSRC is that useful hardware and software
work will eventually become public. After
all, the people there will be developing very
powerful unclassified operating systems. My
contention is that the outside world is catch-
ing up anyway. It is far better to have them
trying to get up to the level of our unclassi-
fied base a few years after us than for us to
have an unclassified base behind that of other
countries and to try to build our classified
technology from it.

Objection 4

(U) If the NSRC is worth having, it's worth
fighting for . We should not regard it as a
political chip to be bargained away for DoE
support for the whole initiative. The best
approach is to keep trying to persuade the in-
terested part ies , especially DoE , that the
NSRC is in their best interest too. They also
will get leverage from having the NSRC solve
their problems.

Feb 84 * CRYPT0L0G * Page 8

OCID

4009895

SHELL

GAME

by WES

TIME

SHELLS [U]

Y ou may not have noticed , but the
time function on our UNIX systems
has been converted to GMT, or ZULU
time- The other day, the phone rang
and the voice at the other end said ,
"The boss would like to see you at 2 :45 to-
day." Since 1 was on the system and probably
would be for most of the day, I typed in

remind 2 :30
See boss at 2 :45

and finished with a control-D. Then, being a
cautious sort (remind has sometimes had a mind
of its own) , I typed in 'delrem' and looked at
what the system thought it was going to do.
By now you have guessed that the system,
operating in the time zone of the mythical
kingdom of ZULU, had stored away my **wake up
call 11 as 1430Z. So much for modern effi-
ciency.

Now 1 don't really mind using ZULU time,
but it's just three more things to remember:
the summer difference, the winter difference,
and which are we in right now. Frankly, I'm
still trying to remember all my PIN numbers
(how many bank cards do you have?), and all
the passwords to the various systems , and a
couple of door combinations, and... well you
get the idea. Every time I get another one of
these important things to remember, I forget
something trivial like a birthday or an an-
niversary.

So I went looking for some, way to get the
system to keep track for me. What I found
were two shells, one short and sweet, and the
other much more involved • Here is the first
one, called "tyrne" :

date "+%H 11 | » t
expr $t - 05 | » t

date "+TIME : ZULU ($t :%M ESI)"

What 1 hadn't realized was how much the
'date' program had changed since UNIX Version
6. Since Daylight Saving Time runs from the
last Sunday of April to the last Sunday of Oc-
tober, 1 added some commands and the shell now
looks like this :

date "+%m" | = a
date ,, +%d" | = b
date "+%w" | = c
expr $b - $c | - d
switch "$a"

: 'standard time'

= e S
- f 05
breaksw

'last Sunday in April change'

if $d -ge 24 then
« e D
- f 04
breaksw

else

* e S

* f 05
breaksw

end if

'daylight saving time'

Feb 84 * CRYPTOLOG * Page 9

DOCID: 4009895

: 09

= e D
= f 04
breaksw

; 'last Sunday in October change'

: 10

if $d -ge 25 then
= e S
= f 05
breaksw

else

= e D
= f 04
breaksw

end if

endsw

date "+%H" | = t
expr $t - $f | = t

date "+T1ME: %H:%M:%S ZULU ($t :%M E$eT) n

At the other end of the scale. I fo und the
shell 'timel', written by | [ in P14.

It begins in the following column.

P . L . 86-36

The original version of Bob's shell uses
reverse video to set up a rather startling
display on the screen. It will also clobber
your terminal if you try to use it across the
network. If you get the original version, you
could insert a test to see whether the termi-
nal of the user was a network terminal, some-
thing like :

switch "$t"

: [X-Z]

(change to net-friendly version •••)

endsw

depending upon how the network terminals are
labelled on your host. Then all you need is a
second version of those lines that have re-
verse video, replacing them with whatever your
artistic heart desires.

After some discussion, we decided to print
the shell without the inverse video, in the
interests of minimizing the chaos around the
TSS community.

goto start

; Bob Jones, P14, 3369-s
: (574 I-s) — 04 Mar 83
: See list of variables at end of file
: start

date "+%H" | = t

date M +%d n | = d

date "+%j" j = c

expr $t - 5 | = 1

expr $t + 3 j = m

expr $t + 09 | = k

expr $t + 11 | * f

if $k -gt 23 then
expr $k - 24 [ - k

expr $d + 01 | * a

expr $c + 1 | = b
else

expr $d + 0 | = a

expr $c + 0 | = b

end if

if $f -gt 23 then
expr $f - 24 | = f

expr $d + 01 | = g

expr $c + 1 | = h
goto skip
else

expr $c + 0 | * h

- g "$d"

expr $g + 0 | = g
end if
: skip

if "$g" -it ”10" then

- g "0$g"

else
end if

if "$d" -It n 10 n then

- d "0$d"
else

end if

if "$h n -It "100" then
= h n 0$h"
else
end if

if "$b n -It "100" then
= b "0$b"
else
end if

if "$f" -It "10 M then
= f "0$f"
else
end if

if "$k" -It "10" then

- k "0$k"
else

end if

if "$a" -It "10" then

- a "0$a"
else

end if

if "$1" -It "10" then
= 1 " 0 $ 1 "
else
end if

if "$m" -It "10" then
= m "0$m"

Feb 84 * CRYPTOLOG * Page 10

OCID : 4009895

FOR OFFICIAL U B S OHLY

date

echo

"+**

»**

LOCAL

DATE:

%h % y

TIME:

§1 :ZM

(EST)

JULIAN

DATE:

%y%3

**»

date

echo

"+**
11 **

ZULU

DATE:

TIME:

St :%M

(Z)

JULIAN

DATE:

%y%j

**»

date

echo

»+**

»**

MOSCOW—

DATE :

TIME:

$m:%M

(C)

JULIAN

DATE :

**»

**"

date

echo

"+**

"**

KOREA

DATE:

TIME :

$k. :%M

(I)

JULIAN

DATE:

%y$b

**"

**»

date

echo

"+**

»**

FIJI

DATE:

$g %h

TIME :

$f :%M

(L)

JULIAN

DATE:

%y$h

**"

pump

** **
**********************************************************************
**********************************************************************

exit

: 'VARIABLES-(refered to as $t, $m, etc) — t or $t= s system hour; d or $d a! system '
: 'date; c=system Julian Day; l=local time; m=Moscow time; k=Korean time; '

; 'f=Fiji Time; The following are computed if the time is after 2400 — '

: 'a=Korean Date; b=Korean J=Day; g*=Fiji Day; and h*=Fiji J^day. '

: 'Other computations such as 'if $m -It 11 10" then' place a zero in front of
: ' '$m'. This, and the statements such as 'if n $h" -It "100" then' are
: 'required because the math functions will drop leading zeros*

: ' ~G — Rings Terminal Bell'

Bob also has a version of this that runs on
the IBM PC in living color. I'm sure he would
be happy to let you have a copy of either ver-
sion.

These shells are more for demonstration
than anything else, and that is the spirit in
which they are presented here. For example,
the first shell does not add a leading zero
when the local hour is less than ten, and will

probably do something weird if the local hour
is less than 5. The third shell doesn't quite
understand what to do at the end of the month
and the 31st day in the land of ZULU may be-
come the 32nd in some other time zone. If
some reader comes up with a good fix, we will
be happy to print it.

Feb 84 * CRYPTOLOG * Page 11

^ II OFriOIAL UGE ONLY

DOCID: 4009895

E.L. 86-36

5J#A-fflr0jstir#53

In case you were born
on February 29th —
Leap Year Day — well
then. Happy Birthday
to you , too !

Feb 84 * CRYPTOLOG * Page 12

OCID : 4009895

BE PART OF THE PROCESS ing

CRYPTO-LINGUISTIC ASSOCIATION
A LANGUAGE AUTOMATION
/K COMMITTEE

presents

Translator/Transcriber Work Station

Are you now using computer power in your language activities?

Will you be using it soon?

Feeling frustrated, intimidated, or uninformed about language automation
in your office?

At the TWS Work Shop you can

* learn about current and future computer systems

* express your ideas

* share your concerns

4-7 June 1984
2W087

Monday, Tuesday, Wednesday 0830-1100

repeated at 1300-1530 *

Thursday Wrap-up 1300-1500

‘*v

All interested Green-Badge personnel invited

See you there!

Feb 84 * CRYPT0L0G * Page 14

FOR OFFICIAL USE ONLY

OCID : 4009895

FOR OFFICIAL U3E OML Y

AUTOMATED
INFORMATION
SECURITY:

[uj

£ ® E0 EIM T. STEEBLE,ca

rP.L. 86-36

I. Computer Security Guidance

A. Policy Requirements

omputer security requirements derive
from the need for the information
processing system to control access
to classified information. These re-
quirements are described more fully in the DoD
CSC Trusted Computer System Evaluation Cri-
teria , 15 August 1983 [ 1 ] . Briefly, such sys-
tems are required to implement the following:

[] MARKING - An ADP system which is used to
process or handle classified or other
definitely categorized sensitive informa-
tion shall clearly store and maintain the
integrity of classif ication or other sen-
sitivity marking labels for all informa-
tion. The system shall assure that the
classified or other sensitive information
is accurately marked when included in
output from the ADP system.

This article is extracted from the
Department of Defense Computer Security
Center's (DoD CSC ) response to the USMC.
The Marines had requested computer securi-
ty guidance and evaluations of several
architectu ral plans . That pape r was au-
thored by | | Chief of

the Applications E valuations Systems Of-
fice, with aid from \ H \ chi e f

Sci entist ■ DoD C omputer Security Center
and 1 | Col , USAF, Deputy Direc-

tor, DoD Computer Security Center. The
COMSEC policy, p rocedures , and gu idance
were supplied by | | COMSEC

Doctrine and Threa t Assessment Office;

I 1 CQMSEC Standards and

Evaluations Office; and | i |

Jr., COMSEC Applications Office .

For this publication minor editing and
revisions, mostl y to delete USMC I specif-
j'cs, were done by | | Chief,

Operational Systems Evaluation Division,
DoD Computer Security Center.

[] MANDATORY SECURITY - The computer system
must enforce the formal system of infor-
mation control reflected in the security
^classification designation and special
handling restriction set associated with
the sensitive information handled or pro-
cessed by the ADP system together with
the clearance set associated with the
individuals who may request access to the
information.

[] DISCRETIONARY SECURITY - The computer
system must enforce access limitations
placed on classified or other sensitive
information based on identified individu-
als or groups of individuals who have

been determined to have a Need-to-Know
for the information.

[] ACCOUNTABILITY - An ADP system which is

used to process or handle classified in-
formation must account for usage on a
named-individual basis whenever classi-
fied information is generated or ac-
cessed .

[] CONTINUOUS PROTECTION - Security-relevant

portions of a trusted computer system
must be maintained under configuration
control to assure that unauthorized
changes have not been made which could
possibly subvert the. system's ability to
control classified information.

Feb 84 * CRYPTOLOG * Page 15

FOR OFFICIAL U S E ONLY

OCID: 4009895

These policy requirements form the basis for
defining security requirements at the system
level, as well as for the hardware and
software components of the system. They also
determine procedural requirements to support
the continuous protection p'olicy and assure
the operational effectiveness of technical
safeguards .

The degree to which a system must comply
with these requirements, either in the use of
specific security features or in the degree of
assurance that the features are effective, is
a function of risk of exploitation. This risk
depends upon motivat ion , capability , and op-
portunity of an opponent to exploit the
system's protection controls and mechanisms.
These factors, in turn, are influenced by such
things as the most sensitive information in
the system, the least restrictive clearance of
system users or those associated with its
development and operation, the hostility of
the environment, and time.

B. System Requirements

A primary system requirement is to have a
clearly defined security perimeter that in-
cludes a suitable combination of manual and
automatic trusted processes to control access
to classified or sensitive data in the system.
Each such process is designed and operated to
implement a well-defined interpretation of DoD
security policy (e.g., minimally, information
that is labeled SECRET will not be accessible
by personnel holding less than a SECRET clear-
ance). The perimeter may be entirely defined
by environmental ( i .e . , physical , personnel ,
and operational security) controls , as is the
case in a dedicated mode of operation. It may
require hardware, software, and COMSEC con-
trols in addition to the environmental con-
trols. For example, electrically connecting
two different computer systems requires
hardware and software controls over the inter-
faces between systems operating at different
system-high levels. These controls must en-
sure, for example, that the , integrity of clas-
sification labels on internal files is pro-
tected and that information flowing from one
system to another is classified no higher than
the maximum authorized for the receiving sys-
tem. This, in turn, requires assurance that
the integrity of classification labels on
internal files is protected in the computers ,
In the multilevel mode one relies very heavily
on controls internal to the computer to en-
force applicable security policy, and thus the
computer hardware and software controls become
an even more critical element of the security
perimeter.

The specific security requirements, both
technical and environmental, to be enforced by
a computer systems application are prescribed
by the Designated Approving Authority (DAA) ,
in accordance with DoD Directive 5200 . 28 or
DCI Computer Security Directive "Security of
Intelligence Information in Automated Systems
and Networks" (formerly DCID 1/16), while the
requirements for determining the technical ef-
ficacy of the system 1 s security controls and
mechanisms are stated in the Center's Trusted
Computer Systems Evaluation Criteria . The DAA
is then required to make an explicit decision
to use the system operationally when convinced
that these security requirements are satisfac-
torily met. We elaborate below on the com-
puter hardware/ so ft ware certification and ac-
creditation process to support this.

C. Hardware Requirements

Computer systems that are trusted to en-
force a security policy employ a combination
of hardware and software mechanisms. The
hardware mechanisms of concern are those that
simplify and optimize the implementation of
access control over the subjects and objects
as defined in the formal security policy model
abstraction. Below we list desirable features
worth considering in the selection of a
hardware architecture. Note that these
features , while helpful, do not supplant the
need for a security kernel. However, they may
improve performance throughput significantly
over the pure use of software controls.

[] Virtual Memory - This hardware feature is
essential. It can be realized in either
a page- or a segmented-based organization
and would provide an effective environ-
ment for multiple processes. Both re-
quire address mapping circuitry that au-
tomatically provides access checking dur-
ing address translation.

[] Execution Domain - It is minimally essen-
tial that the hardware support two execu-
tion domains (preferably three), where
one domain is privileged and protected
from the less privileged domain. Secu-
rity kernel software runs within the most
privileged domain, and untrusted user
software executes within the less
privileged domain(s).

[] Controlled Access to I/O Devices - It is
essential that computer architecture pro-
vide some mechanism that enables a secu-
rity kernel to maintain control over
accesses to input/output (I/O) devices.
A sufficient solution is the notion of

Feb 84 * CRYPTOLOG * Page 16

DOCID: 4009895

privileged I/O operations. Here, I/O is
performed only by a process executing in
the appropriate privileged domain. The
kernel must control access to this
privileged state .

[] Multiple Processes - Many users normally
share concurrently the available
resources of a general-purpose computer
system, therefore the base computer ar-
chitecture must provide support for an
efficient multiple— process structure.
The minimal hardware support necessary is
the capability to save and restore pro-
cess definition information.

Additional information may be found in MITRE
Technical Report No. ESD-TR-78-170 "Minicom-
puter Architectures For Effective Security
Kernel Implementations" by John D. Tangney ,
dated October 1978.

Because of the reliance one has on these
controls , there are several security concerns
to be addressed in the acquisition and use of
this hardware . One concern is correctness .
Assurances must be given to show that the
hardware mechanisms have been designed and
built to function correctly. A second concern
is rel iabil ity . Failures in the hardware must
not weaken or eliminate the security controls
that are implemented in the hardware itself or
in the software which , in turn , requires
correctly functioning hardware. A third con-
cern is integrity . Configuration control
measures during hardware design, implementa-
tion, operation, and maintenance must deter
accidental or deliberate modifications of the
hardware that can cause security controls to
be bypassed or weakened. The degree of con-
cern in each area and the corresponding steps

taken to reduce the risk is application-
dependent . Although exploiting such avenues
of vulnerability is possible, one must con-
sider them in the context of other areas which
could be more susceptible to attack (e.g.,
software) .

In those cases where the hardware will be
used in a periods processing mode, it should
permit rapid and reliable erasure of all
internal memory (e.g., primary storage, non-
removable secondary storage and buffers). It
must also support the capability for a physi-
cal disconnect from those other devices in
areas with a lesser degree of protection.
There is ongoing research as part of the con-
solidated DoD Computer Security R&D program to
develop a "job stream separator" which au-
tomatically and reliably performs all neces-
sary color change procedures.

In those cases where the computer will
simultaneously process or store information of
different classifications, the hardware should
support internal labeling of files with the
appropriate security classification, and these
internal labels should be used as the primary
basis for access control decisions. This is
particularly the case if the system users are
not al 1 authorized access to all of these
files (e.g., a9 in the controlled or mul-
tilevel mode of operation). A similar re-
quirement may exist for systems which process
personnel proprietary or other sensitive un-
classified information.

Individual hardware components must meet
TEMPEST requirements commensurate with their
operational environment, current policy, and
the perceived threat of exploitation.

Feb 84 * CRYPTOLOG * Page 17

bOCID: 4009895

D. Software Requirements

E . Procedures

Software that must enforce DoD security
policy must be designed, implemented, and do-
cumented to permit credible evaluation and ve-
rification that it, in fact, correctly en-
forces that policy. This requirement would
have to be applied to all system software in-
cluding the operating system, system utili-
ties, data base management systems (DBMS),
compilers, or application software. Such
evaluation would be difficult and lack credi-
bility if the security-relevant mechanisms are
complex and scattered throughout the software.
One simply cannot determine that an unstruc-
tured collection of these mechanisms correctly
implements the policy and cannot be circum-
vented. Thus, the Center requires that in
trusted computer systems all security-related
functions be implemented in well-defined por-
tions of software, firmware, and hardware, the
totality of which is called the trusted com-
puting base (TCB). The TCB must be designed
and implemented so that its security controls
are always invoked and are tamperproof, that
is, the controls cannot be modified or
bypassed by the remaining (untrusted) portions
of the system and that they be of sufficiently
simple design as to be subjected to thorough
test and analysis . During its design and
development , the TCB is subjected to specifi-
cation and design analysis verification and
testing to assure that these properties are
indeed satisfied. The DoD CSC Trusted Com-
puter System Evaluation Criteria amplify these
requirements further.

Determining the specific requirements for
software controls and level of assurance,
i.e., the evaluation class, for a particular
application must reflect the level of risk and
degree of trust required of the hardware and
software. One indicator of this is security
range that is, the difference between the
classification of the most sensitive informa-
tion and the least restrictive user clearance.
Thus, for example, a Class C2 system may pro-
vide adequate trust for a system-high applica-
tion. A multilevel mode application would, on
the other hand, normally be expected to meet
the criteria of a Class B2 or higher system,
depending on its security range.

The continuous protection requirement is
primarily satisfied with procedures to control
and monitor access to hardware and software
security components during their design and
implementation, and then during their opera-
tional life cycle. Such procedures are a
critical part of gaining assurance that the
security mechanisms are designed and built to
meet stated requirements and then maintained
and used to remain effective. Specific re-
quirements include:

[] clearing system support personnel to the
highest level of data in the system;

[] clearing maintenance personnel commen-
surate with the sensitivity of informa-
tion to which they could get access; and

U developing and maintaining software which
protects sensitive information in an en-
vironment consistent with the sensitivity
of the data being protected and with a
level of risk that is acceptable to own-
ers of sensitive information.

In systems which involve periods process-
ing, accreditable procedures are needed to
change processing classification levels. Pro-
cedures include removing sensitive data from
the system, disconnecting or reconnecting
peripheral devices and remote terminals , and
rebooting the appropriate operating system at
the new processing level.

F. Classified Software

The security mechanisms and their implemen-
tation in trusted system hardware and software
are generally unclassified. However, as noted
earlier, this software may be treated as if it
were classified to meet the continuous protec-
tion requirement. There may be instances in
which security-related software is classified
(e.g. , if it implements a classified crypto-
graphic algorithm) or security-related
software contains classified data (e.g., the
routing tables in a message system) . Such
software must be protected like any other
classified information while it is stored in L

the computer. There may be multiple copies of
it in primary and secondary storage, all of
which must be labeled and protected, as must
all hardcopy printouts of it.

Feb 84 * CRYPTOLOG * Page 18

FOR OFFICIAL T . T S B ONLY

DOCID: 4009895

G. General ADP Security Cert ificat ion/ Accreditation

Planning Guide ( reference #2) prov ides add i-
It is DoD policy that all ADP systems which tional information on the critical steps in

process classified information will be ac- the certification/ accreditation process,

credited; that is, there will be an explicit Further direct interaction with the user,

decision that the system adequately protects designer, and C2 could follow the reading of

information and can be used operationally. this literature and enable C2 to work on

This accreditation is frequently based upon a recommending or finalizing a recommended

technical evaluation of the system to deter- secure system,

mine how well it meets predefined require-
ments. However, unless the system is designed
and built to be evaluated, as is NOT the case
with most existing computer systems, the
technical evaluation consists almost entirely
of looking for flaws in the system or conduct-
ing tests of the system's ability to withstand

penetration. Neither case gives assurance II. Telecommunications

that the system is secure because such exhaus-
tive testing never finishes. Thus, it is vi-
tally important that security requirements be A well-defined, layered network security

identified early in the system's development. architecture is needed that
It is equally important that the system secu-
rity architecture identify trustworthy mechan- [] addresses all the threats of concern to
isms to control the flow of information into, the user; and

out of, and within the system. One can then
determine explicitly the policy model which [ ]

each trusted hardware and software component
of this architecture must enforce and the ap-
propriate Trust Class as described in the Cri-
teria. One can then specify, implement, ver-
ify, and certify that those enforcement It is desirable to have a single, layered,

mechanisms that are implemented correctly en- inter-network security architecture that can

force the policy. To assist with this, there be deployed across all DoD certified nets. An

is a growing collection of formal design and ambitious DoD effort is under way to achieve

verification methodologies which can be used. this initiative.

These include SRI ' s Hierarchical Development
Methodology, University of Texas 1 GYPSY sys-
tem, and SDC's Formal Development Methodology.

The C organization is undertaking an effort to III. Policy

make these tools more easily available to and
usable by system developers as well as by NSA

and DoD system test and evaluation organiza- Electrical Interfaces - Electrical inter-

tions . faces between systems operating at different

classification levels must ensure that only
appropriately classified information flows
Computer vendors, (i.e., DEC, UNIVAC, from the more sensitive to the less sensitive

Honeywell, etc.) have developed or are system. It must also prevent users of the

developing trusted systems which might meet less sensitive system from making unauthorized

long-range requirements. Additionally, changes, accidentally or deliberately, to data

software houses are developing add-on packages in the other system or from disrupting its

to provide a little increase in software secu- use. A manual interface has, until recently,

rity (i.e., SKK* s ACF2 , IBM 1 s RACF, CGA 1 s Top been the accepted method. However,

Secret , etc. ) . In Section III below we note trustworthy devices for controlling such in-

other possible uses of trusted systems as part terfaces have been proposed for several sys-

of the security architecture . Thus , a first terns . One such device currently in develop-

step in developing the architectural strategy ment will use the Honeywell SCOMP as a basis

and planning for using trusted systems would for implementing a GUARD to allow SECRET users

be to determine what the long-term security to access SECRET data bases on the US Army

requirements are (i.e. will multilevel secu- Forces Command's Top Secret system-high WWMCCS

rity become an operational necessity, and if computer. There is another approach which

so, over what range of classification and user uses a cryptographically derived cryptographic

clearance?). check to verify the releasability of informa-

tion when it is being electronically trans-
ferred between security perimeters (reference
#3).

is consistent with, or is at least not
incompatible with, the security architec-
tures of networks to which various users
are connecting.

Feb 8A * CRYPTOLOG * Page 19

CID : 4009895

T OR O FF ICIAL UOC OHLV

*-Property[2] - DoD security policy for ADP
systems was discussed in Section I above. The
*-property is one part of the Bell & La Pa-
dula[3] policy model for mandatory security.
It is more conservative than DoD policy as it
relates to paper documents but it precludes
the success of Trojan Horse attacks.

Data Aggregation - DoD policy for correct
classification and handling labels for data
elements (alone or in aggregate) should be im-
plemented in data processing systems. This
requires reliable labels on internal files and
on output giving the classifications or other
special handling instructions, as determined
by the owner of the information at the field,
record, file, or data base level, as appropri-
ate.

Data Encryption Standard (DES) - Present
policy requires that NSA approve, on a case-
by-case basis, any proposed use of DES to pro-
tect classified communications. With respect
to the use of DES to protect unclassif ied, na-
tional security-related communications, re-
cently issued national policy requires that
Services, Departments, and Agencies determine
the risk of exploitation of their unclassified
communications, either in consultation with or
based upon prior guidance from NSA in accor-
dance with Federal Standard (FS) 1027. Where
there is high risk of exploit at ion, NSA will
prescribe or approve the cryptographic system
used, on a case-by-case basis. For all other
applications , commercial cryptographic systems
(to include DES) may be used if they have been
endorsed for general application by NSA.

IV. General

There will be additional costs associated
with implementing, using, and maintaining phy-
sical, emanations, personnel, and procedural
security safeguards. Some of this additional
cost (e.g., for physical and emanations safe-
guards) is part of the capital investment. On
the other hand, the costs for personnel and
procedural safeguards are part of the opera-
tional costs. The actual costs for a facility
depend upon the level of protection required
for the information being processed in a given
threat environment. There will also be addi-
tional costs associated with acquiring and us-
ing trusted computer systems. Designing secu-
rity into the system can lower these costs and
have a beneficial payoff through improved re-
liability and maintainability which results
from a well-structured software design and im-
plementation. We note that there are two key
aspects to be considered in estimating the
cost of safeguards in these security areas.
They are (1) what level of protection is re-
quired, and (2) how must these, safeguards be
used and maintained to ensure their continued
effectiveness?

[Doesn't protection of
and products require this?

sources,

EFS]

methods ,

Footnotes

1. This and the other referenced papers can
be obtained from the DoD CSC Technical
Library (C422).

2. Pronounced "star property"

[was recently hired as Deputy

Chief of C3.

P.L. 86-36

Bibliography

1. Trusted Computer System Evaluation Cri-
teria, CDC-STD-001-83, 15 Aug S3 “fs 3

225,711).

2. ADP Security Cert if icat ion / Accreditation
Planning Guide , undated.

3. On the Feasibility of Connecting RECON to

an External Network , | ""|

dated 16 Mar 8.1 .

P.L. 86-36

Feb 84 * CRYPTOLOG * Page 20

FOR OFFICIAL USE ONLY

DOCID:

EO 1 . 4 . (
P.L. 86-

feO‘4..- 4 .

P.L. 8 6-

P.L

4009895

■36

EO 1.4. (c)
P, . L . 86-36

SECRET

(c)

-36

CRYPTOLOG
1983
INDEX CU)

t> , Ij . 86-36

TITLES

Acronymania; Hoy 83 f
Ada News; Jan $3;Q"

Ada: Conquering the Tower of Babel; Jan 83;

J Apr 83 ;[

Announcement: Contributions Solicited for
CRYPTOLOG Articles; Sep 83;

Announcement: KRYPTOS Society Spring Meeting;
Mar 83;

Announcement: Request for Copies of Jan-Feb 83
Issue (CISI Essay Contest); Aug 83;
Announcement: Students! (NCEUR Independent

Study Programs); Mar 83;

Announcement : Two New Lan guage _Ajds| I

1 ( and Chinese-Engl ish) ; Jun 83;

The following is a cumulative index of
CRYPTOtOG (Vol X , 1985) and is in three

parts, by title, by author, and by key-
word. Items in multiple issues (January-
February 1983, for example) are indicated
by the first month (i.e., by Jan 83).

Cumulative Index (1974-1982), Part 1: Authors;

Mar 83 ;

Cumulative Index (1974-1982), Part 2: Titles;

Apr 83; ....■■■■ ;/ ‘5 . L . 8 6-3(

Cumulative Index (1974-1982) , Part 3:

Keywords; May 83;

DCL; The Direc t Communications Link; Dec 83 ;

Do You Know the Differences?; Jun 83; | \ \ |

D.S.

Do You Really Mean Julian?; Sep 83; |

C .

Does Your Office^ Make You Sick?; Aug 83;

E.T. At NS A; Mar 83;

FBIS Latin American Reference Aid; Apr 83;

11975-77 ; Sep 83: I I

1982; Sep 83;|_

] Apr 83;

5-4-^^dzz^^^ Nov 83; 'Watt Zizn ame 1
Foreign Microwave Radio; Sep 83: 1 I

Frontier Dentist; Apr 83;

'Marian D . Librarian'

The Futu re Brightens fo r Flat-Panel Displays;

Jan 83:1 \

Getting Personal; Jan 83; | |

Government of the People , By The Party, Fo r
The Leadership; Apr 83 >| I

] Jun

*; ! ~l~

I Remember jfk; nov 83; H.G.R
I Remember Mabel Babel; Aug 83 Q

| | __ 0 , . , Improving Raster G raphics Ima ges

Bann ers. Cowboy Ha ts, and ELINT Notations; Oct Aliasing ; Jan 83 ; | |

83; I I

v.L . 8 6-36

The Case of the ' Fowled-Up' CRITIC; Aug 83;

0 , I 1 I

The Intelligence Watch Officer; May 83; |

L.S.

I l l . .

J Nov 83 ; ^

The Islamic Time Bomb; Dec 83 ;|

Computer Graphics to Enhance Collection
Management; Jan 83

Computerizing T raffic Analysis; May 83;
Confessions of a Briefer; May 83|; |

omputerizing of TA,

Correction: Do Ybu Know the Differences? ,
Jun-Jul 83 Issue; Aug 83;

Correction: October 1983 CRYPTOLOG Issue Add
to Classification: 'REL UK CAN AUS NZ'; Dec

83; jl

Crisis Management: Remarks; Oct 83; | |

L.D. ii /

Cryptic Crossword #3; Mar 83: 1
Cryptography At GLOBECOM 82; May 83,;[

J. A.

F.W

Letter to the Editor:

May 83 Issue; Nov 83

Letter to the Edito r: Governme nt of t£g) 1 . 4 . (d)
^People... reply toj | letter^ ^ug §%J_ 36

Letter to the Editor: Government of the

People. . . , Apr 83 Issue; Aug 83;

Letter to the Editor: Management of
Coordination, Sep 83 Issue ; Oct 83;

'Juan Tuthri 1

Letter to the Editor: My S taff — It Comfort s
Me, Apr 83 Issue; Aug 83 ; | |

] Letter to the E ditor: Out of My Depth, May 83
Issue; Aug 83; | |

1.4. (c)

. 86-36

P.L. 86-36

Feb 84 * CRYPTOLOG * Page 21

DEOIIET

OCID : 4009895

JEORET

M . L . 8 6-36

/yfevL. 8 6-36

Letter to the Editor: Redb aron, i Road run ner . . ■ ,
Jun-Jul 83 Issue; Sep 83 : 1'' / / / 1 1 \

Letter to the Editor: . Classified

Information; Jun 83; I ^ I

Letter to the Editor: The Tower of Babel; May
83; Mo Hick J.J. | \

Letter to the Editor: Tips on Topical

Reporting, Oct 83 Issue; Dec 83; \
Letter to the Editor : Tips on Topical
Reporting, reply to l ~"T letter;

Dec 83;

Letter to the Ed itor: UNIX ED (I) Manual Page
Comment ; Oct 83 J I

Letter to the Editor: Video Teleconfere ncing,
Mar 83 Issue; Jun 83 ; J i |

The Literary Bends; Noy 83; Murphy jA. I.

Logic De sign Exceeding Boolean Capabilities;
Jan 83 ; | f

MBTI: The Management Tool of the Future; Nov

83; l ~l

Man Does Not Live By Matzos Alone; Apr 83;

'Marian D. Librarian 1 ^

Management of Coordination; Sep 83; I

Managing Ou r Systems for Performance

; Jan 83;

Menu Selection As A T ool for Human/Ma chine
Interaction; Jan 83: 1 ~ 1

Mar 83; |

1 Dec 83:1 ~

Internet Archive Audio

Featured

Top

Images

Featured

Top

Software

Featured

Top

Texts

Featured

Top

Video

Featured

Top

Mobile Apps

Browser Extensions

Archive-It Subscription

Save Page Now

Full text of "cryptolog_87-nsa"

See other formats